\documentclass[landscape,a0b,final,a4resizeable]{a0poster}
%\documentclass[landscape,a0,final]{a0poster}
%\documentclass[portrait,a0b,final,a4resizeable]{a0poster}
%\documentclass[portrait,a0b,final]{a0poster}
%%% Option "a4resizeable" makes it possible ot resize the
%   poster by the command: psresize -pa4 poster.ps poster-a4.ps
%   For final printing, please remove option "a4resizeable" !!

%\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{multicol}
\usepackage{pstricks,pst-grad}
%\usepackage{natbib}

%\bibpunct{(}{)}{;}{n}{,}{,}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Definition of some variables and colors
%\renewcommand{\rho}{\varrho}
%\renewcommand{\phi}{\varphi}
\setlength{\columnsep}{3cm}
\setlength{\columnseprule}{2mm}
\setlength{\parindent}{0.0cm}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%               Background                     %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newcommand{\background}[3]{
  \newrgbcolor{cgradbegin}{#1}
  \newrgbcolor{cgradend}{#2}
  \psframe[fillstyle=gradient,gradend=cgradend,
  gradbegin=cgradbegin,gradmidpoint=#3](0.,0.)(1.\textwidth,-1.\textheight)
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%                Poster                        %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newenvironment{poster}{
  \begin{center}
  \begin{minipage}[c]{0.98\textwidth}
}{
  \end{minipage} 
  \end{center}
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%                pcolumn                       %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newenvironment{pcolumn}[1]{
  \begin{minipage}{#1\textwidth}
  \begin{center}
}{
  \end{center}
  \end{minipage}
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%                pbox                          %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newrgbcolor{lcolor}{0. 0. 0.80}
\newrgbcolor{gcolor1}{1. 1. 1.}
\newrgbcolor{gcolor2}{.80 .80 1.}

\newcommand{\pbox}[4]{
\psshadowbox[#3]{
\begin{minipage}[t][#2][t]{#1}
#4
\end{minipage}
}}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%                myfig                         %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \myfig - replacement for \figure
% necessary, since in multicol-environment 
% \figure won't work

\newcommand{\myfig}[3][0]{
\begin{center}
  \vspace{0.1cm}
  \includegraphics[width=#3\hsize,angle=#1]{#2}
  \nobreak\medskip
\end{center}}

%    \begin{figure}[h]
%    \centering
%    \center{\psfig{figure=gklogo.eps,width=2.5in}}
%    \caption{Format of a DPB object.}
%    \label{fig:format}
%\end{figure}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%                mycaption                     %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \mycaption - replacement for \caption
% necessary, since in multicol-environment \figure and
% therefore \caption won't work

%\newcounter{figure}
\setcounter{figure}{1}
\newcommand{\mycaption}[1]{
  \vspace{0.2cm}
  \begin{quote}
	\small
	\centering
    \textbf{{Figure \arabic{figure}: #1}} %    \textbf{{{\sc Figure} \arabic{figure}: #1}}
  \end{quote}
  \vspace{0.2cm}
  \stepcounter{figure}
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Begin of Document
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

\background{1. 1. 1.}{1. 1. 1.}{0.5}

\vspace*{2cm}


\newrgbcolor{lightblue}{0. 0. 0.80}
\newrgbcolor{white}{1. 1. 1.}
\newrgbcolor{whiteblue}{.80 .80 1.}


\begin{poster}

%%%%%%%%%%%%%%%%%%%%%
%%% Header
%%%%%%%%%%%%%%%%%%%%%
\begin{center}
\begin{pcolumn}{0.98}

\pbox{0.95\textwidth}{}{linewidth=2mm,framearc=0.3,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{

%%% Unisiegel
\begin{minipage}[c][6cm][c]{0.1\textwidth}
  \begin{center}
    \includegraphics[width=10cm,angle=0]{University_logo.png}
  \end{center}
\end{minipage}
%%% Titel
\begin{minipage}[c][4cm][c]{0.78\textwidth}
  \begin{center}
    {\sc \Huge Real Time Bus Location Tracking}\\[10mm]
    {\Large L. Haub, F. Hudson, J. Keen and K. Nguyen\\[7.5mm]
   Mobile \& Wireless Networks, Honours Computer Science, Adelaide University, Australia}
  \end{center}
\end{minipage}
%%% GK-Logo
\begin{minipage}[c][4cm][c]{0.1\textwidth}
  \begin{center}
    %\includegraphics[width=3cm,angle=0]{../res/drawable-hdpi/finished_asset.png}
  \end{center}
\end{minipage}

}
\end{pcolumn}
\end{center}


\vspace*{2cm}

%%% Begin of Multicols-Enviroment
\begin{multicols}{3}


%%% Objective
\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Objective}\end{center}}\end{center}
\vspace{0.15cm}

%What we set out to do:

The project set out to enable viewing of real time bus location and scheduling information on a mobile device. For this task an Android application would be developed as a prototype for a system that would target public transportation authorities worldwide with the promise of providing a useful public service. The exchange of information between busses and mobile devices to enable location tracking would work as shown in Figure 1, below. %Figure 1 depicts our view of how location tracking would work. ?

%A top level overview of the exchange of information between busses and mobile devices to enable this tracking is shown in Figure 1.

\begin{center}
  \myfig{../screenshots/topLevelArchitecture.png}{0.7}
  \mycaption{Exchange of information between busses and mobile devices to enable real time location tracking. }
\end{center}

%%% Introduction
%\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Introduction}\end{center}}\end{center}
%\vspace{0.15cm}

%Our application DroidBus, is a bus tracking system for your mobile phone. Similar to applications being developed around the world such as BusTrack \cite{chicago} for the Chicago public transportation service, it aims to provide real time location information on Adelaide Metro services, but distinguishes itself from BusTrack and others by providing this information graphically and on a mobile device. 
%. DroidBus allows you to see the current location of busses and their route and stop information graphically.

%%% Innovation
\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Innovation}\end{center}}\end{center}
\vspace{0.15cm}

Existing applications that provide real time location information for public transportation systems include systems such as Bus Tracker \cite{chicago} and NextBus \cite{nextbus}. Both of these services, however, only provide location information to a desktop web browser and textual schedule information to mobile device users over SMS.  Our application DroidBus distinguishes itself by providing this location information in an interactive and graphical manner tailored for a mobile device. 

\vspace{1cm}

With respect to scheduling data, most of the existing services such as printed timetables, the Nomad application \cite{nomad} and Google Maps' itinerary planning are based on static schedule data. As for live data, Adelaide Metro is currently trialling 32 Smart Stops \cite{metro} that provide users at the stop with the time a bus will reach the stop. Our application would provide the functionality of the Smart Stops to a user anywhere at any time and provide real time adaptive schedule and itinerary planning information to a mobile device user. 

%Applications such as Bus Tracker \cite{chicago} for the Chicago public transportation service and NextBus for a number of American transit agencies already exist and provide real time bus location information to users, but to a desktop web browser. Their mobile service provides only text based schedule information over SMS. Our application DroidBus distinguishes itself by providing this information graphically and tailored for a mobile device. 

%Nowadays, there are several applications that allows users to get the real time location information of the public transportation such as BusTracker[Aut] for the Chicago public transportation or NextBus for all American public transportation services. However, their services only provide information of the buses via SMS or websites. Uniquely, DroidBus can provide these real time information visually via a mobile phone. This application can be seen as the combination between GoogleMap and Nomad application of Adelaide metro. When using DroidBus application, user could see not only the itinerary information but also the real time location information of the bus which are displayed on the mobile screen.

%Existing scheduling services include the 32 Smart Stops being trialled by Adelaide Metro \cite{metro} to provide users at the Smart Stop with the time a bus will reach the stop. Additionally, Google Maps is able to plan an itenerary using public transporation for a user entered departure and destination location. Our application would provide this Smart Stop schedule information to a user anywhere at any time and provide real time (vs timetable based) itinerary planning and progress information. 

%Google Transit \cite{transit} is able to plan an itenerary for the busses to be taken and stops to get off at for a user entered departure and destination location. It does not provide any real time information, but does the scheduling we would require. 

%Connector bus thingo. 

%Smart Stops
%Adelaide Metro already trials a similar system through 32 Smart Stops in the city, Henley Beach and Seaview roads and The Parade.
%Buses operating on Smart Stop routes are fitted with GPS navigation units and an on-board computer.
%Ticketing and GPS data are fed into Adelaide Metro's main computer system, which then predicts what time a bus will reach its next stop based on where the bus is and past travel times from that point to the Smart Stop.
%Predicted travel time information is relayed to the bus stop and displayed on the Smart Stop display – visually and via audio announcements at the touch of a button.

%%% Challenges
\vspace{0.15cm}\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Challenges Faced}\end{center}}\end{center}\vspace{0.15cm}

%Some of the main challenges we came up against in this project.\\

 %      Displaying Map Images:
 %              We knew we would have to display map tiles that we could scroll and zoom.  We
%would have to source them from somewhere (OpenStreetMap would have been one
%possibility relatively free of legal problems), we would have to get them to the
%user's device quickly and at minimum bandwidth cost, and we would have to
%manipulate them on the device, and match them to latitude and longitude values.
 %This was going to be a relatively large amount of work, and probably a source
%of a large number of difficulties.
 %      Solution:
  %             We simply used the Google Maps API within Android to make their maps available
%to our users.

%Obtaining access to bus GPS data:

%\vspace{0.3cm}
               We had hoped to be able to work with Adelaide Metro - use their GPS data for buses along Smart Stop routes
with GPS devices fitted. Despite promises from the relevant people and repeated follow up calls, it became clear that we would not be provided with access to their data. As a result we had to set up our own test server to provide simulated data. %Excited about the possibilities of the project we wanted to continue and this necessitated setting up our own test server to provide simulated data. %This necessitated 
%After seemingly positive initial contact with relevant people within the company, repeated attempts at follow up communication were not reciprocated and we g

\vspace{1cm}

Our initial plan involved providing scheduling and itinerary planning to the mobile user. A feature to provide an optimal route from the user's current location to any destination was was written to near completion before limitations of the Google Maps API were revealed, possibly due to do with a licensing issue on the data provided to Google by Adelaide Metro. Regardless, the initial scope of the project was realised to be too ambitious to be achieved within the timeframe and we scaled back our plans to providing real time location tracking as the main function. %Future work would add the missing functionality.  


%Our initial plan for the project involved providing scheduling, timing and directions to the mobile user. A target that we soon realised would was too ambitious to be achieved within the limited timeframe of the project, but would likely be added in future work. In particular, we had planned to have a function available to the user to give them an optimal (or near optimal) route from their current location to any destination. Without the time to write our own implementation we had written to near completion an implementation using the functionality provided by the Google Maps/Transit API. Unfortunately, the API only provides direction for driving or walking possibly to do with a licensing issue with Adelaide Metro. 

\break

\begin{center}
  % first argument: eps-file
  % second argument: stretching-factor relative to Column-width (<1)
  % optional argument: rotation angle (0-360), default=0
  \myfig{../screenshots/NexusThreeViews.png}{1}
  \mycaption{Three views of the application, coloured pins represent busses.\\ Left: An overview of the 99B route showing two busses currently on that route.\\ Centre: A view of all of the busses in the vicinity and the four menu options available.\\ Right: A close up view of the 99C route with bus stops, numbered pins, shown. }
\end{center}



%               We planned to have a function available to the user that would give them an
%optimal (or near optimal) route from their current location to any other chosen
%location, using the buses we had data for.
%       Solution:
%               Google offers almost the exact function in Google Maps, so our first step was
%to look at the Google Maps API.  Unfortunately the API only gives directions for
%driving or walking.  We thought we had a way around this restriction by
%requesting a Google map with directions and adding "output=kml" to the end of
%the URL.  This successfully requests the directions data in a kml file, but
%unfortunately we didn't notice until too late that when the "dirflg" parameter
%is set to "r" (public transit) the kml file returned is empty.  By this time we
%had already written code to request, parse, and draw the route data.
%               With the deadline fast approaching, we had to abandon this feature.


%%% Methodology
\vspace{0.15cm}\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Methodology}\end{center}}\end{center}\vspace{0.15cm}

%Figure 2 shows three main views and usages of the application.

The client side application (shown in Figure 2) uses the Google Maps API to display the user's location overlaid with bus, route and stop information. An interface was used between the client application and the server to allow for a trivial change of the source of data. A minimal set of assumptions were made on the data retrieved from the server to enable the application to be easily used by bus companies in other cities. It was assumed that the server would minimally provide longitude, latitude and route number for every bus. %This minimal set of assumptions were to enable the application to be easily used by bus companies in other cities.

%it would provide longitude, latitude, route number and and identification string for every bus at every request

%???????List assumptions for technical details.

\vspace{1cm}

%The original intention for this project was to make the app work with data from Adelaide Metro services, but as contact with them was entirely one way, a test server with a bus simulator was used instead. 

The aforementioned test server was created using Java Enterprise Edition and the Apache Tomcat open source servlet container to serve data from a desktop computer. A single Java Servlet class responds to HTTP requests by executing a doGet method for every HTTP get request at a specific address on port 8080. The servlet checks the URL for options and responds with the requested data. The servlet uses route files to automatically generate the location of each bus and update them on a timer to simulate real data. 


%%% Usage
%\vspace{0.15cm}\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Usage}\end{center}}\end{center}\vspace{0.15cm}

%Upon launch the user is presented with the location of all of the busses (centre of Figure 2). Tapping on a single bus, hides all busses except for busses on the same route and displays the route as a coloured overlay (left of Figure 2), bus stops can be optionally shown (right of Figure 2). A further tap on any bus will again show all of the busses. A simple menu system (bottom of centre of Figure 2) provides access to filtering the busses down by selection from a list, versus having to tap on the desired bus, and the ability to display multiple routes at once and other useful functions. 

%\vspace{0.5cm}
%There are a few menu options (as shown in centre of Figure 1):
%\begin{itemize}
%\item Filter busses: allows the user to show one or more busses by selecting them from a list, versus tapping on a bus.
%\item Show all busses:  returns the user to the view of all of the busses. 
%\item Show me: centres the view on the user's location. 
%\item Show/hide stops: allows the user to show or hide bus stops on the routes (stops are shown in view on the right of %Figure 1). 
%\end{itemize}

%\break


%, also showing the menu options: filter busses, allows user to show one or more busses by selecting them from a list, show all busses, is able to return to the view of all of the busses, show me, centres the view on the user's location, show/hide stops, allows the user to show or hide bus stops on the routes.

%%% Architecture
\vspace{0.15cm}\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Architecture}\end{center}}\end{center}\vspace{0.15cm}

The mobile application was written using the Android 2.1 SDK in the Java programming language. Figure 3 depicts the structure of the client side of the application and the connection between the client and server sides. The connection package contains an interface implemented by two classes; Connection and TestData that provide data from the test server as well as static data that was used while setting up the test server respectively. 

\vspace{1cm}

The elements package consists of the real world items that are modelled by the application; busses, bus stops and routes. The ui package contains the DroidBus class which is the main application activity run on the device with inner classes; RoutesOverlay, BusStopOverlay and BusOverlay which handle drawing of the elements on the map and supporting classes; Markers and Colours that produce the pins and colours used when drawing.

\vspace{1cm}

Figure 4 depicts the server side of the service that consists of logic to simulate Bus objects along test routes and the method that is run when a HTTP get request is received. 

\begin{center}
  \myfig{../assets/clientandconnarc.png}{1}
  \mycaption{UML diagram of the structure of the client side of the application and the connection between the client and server sides.}
\end{center}

\begin{center}
  \myfig{../assets/serverarc.png}{0.4}%was 0.5
  \mycaption{UML diagram of the structure of the server side of the service.}
\end{center}

%\begin{center}
%  \myfig{../assets/connectionarc.png}{0.5}
%  \mycaption{UML diagram of the connection interface between the client and server.}
%\end{center}

%%% Future
\vspace{0.15cm}\begin{center}\pbox{0.8\columnwidth}{}{linewidth=2mm,framearc=0.1,linecolor=lightblue,fillstyle=gradient,gradangle=0,gradbegin=white,gradend=whiteblue,gradmidpoint=1.0,framesep=1em}{\begin{center}\textbf{Future Work}\end{center}}\end{center}\vspace{0.15cm}

This project has culminated in functional prototype. Before a real deployment of the application that could involve thousands of users, optimisation of resource usage and evaluation of the load on the data server(s) should be explored. This is necessary since the prototype has not placed emphasis on efficiency over ease and speed of development (due to the short project timeframe), for example, by using plain text as the transmitted data versus compressed data, using a fixed two second polling schedule versus a variable schedule and by sending data for all busses to each user versus a subset of the busses that the user might select. Furthermore, future prototypes would likely add the missing scheduling and itinerary functionality as intended and port the application to other smart phone platforms.

%An Android application was chosen to be developed because of the groups familiarity with the Java development environment, however, the application would be readily portable to other smart phone platforms: iOS, Windows Phone 7, Blackberry etc. 

%For instance, the app currently polls every two seconds, but testing may reveal a longer interval acceptable to users, perhaps 5 or even 10 seconds, or maybe a short interval when the app is started and then moving to a longer interval later, would help to reduce data usage. Furthermore, realistically the user will only want to see a few of the services of the bus company, thus, the ability for the application to request only a subset of the data - data for only some buses, not all, would further reduce bandwidth use. 

%Add back the scheduling timing and itinerary planning


%%%%%%%%%%%%%
%%Fergus, what you had written was really good, but way too much. I'm hoping we can give them (the lecturers) a small report to acompany the poster with the uml diagrams, as they are just not gonna fit on the poster. 
%%%Refer supplemenataryinfo.tex



%\subsection{Features}
%Time permitting, there are a number of features that would be added to the app, or at least tested:
%Extensions that could be added:
%\begin{itemize}
%\item Directions: a function to find the quickest route by public transport from the user's location to any other location.  Would be similar to the Google Maps function that does the same, if not actually using the Google service.\footnote[1]{This was written almost to completion, but was not included because it was finally noticed that there was no way to use Google Directions data for Public Transit.  Only Walking and Driving were possible.}
%\item Arrow indicators for buses: Arrow that indicate the direction of travel of buses.  Perhaps a toggle to enable/disable this to avoid cluttering the screen.  Would be useful for long update intervals and zoomed out views.
%\item Time to reach user: a function to display the estimated time a chosen bus will reach the closest point on it's route to the user (or another specified location).
%\item Speed: function to display current average speed of chosen bus (or all buses).
%\item Stopped indicator: display a different icon for buses that have stopped.
%\item History Trail: option to begin drawing trails behind buses, to show history from time activated.
%\item Sift buses/routes by location: function to show only routes that come within a certain radius of a selected point (or perhaps buses that are currently within a certain radius).  The radius could be static or adjustable by dragging.
%\end{itemize}


%%% References
\begin{flushleft}
\bibliographystyle{unsrt}
\bibliography{poster.bib}
\end{flushleft}



\end{multicols}

\end{poster}

\end{document}


Adelaide Metro already trials a similar system through 32 Smart Stops in the city, Henley Beach and Seaview roads and The Parade.

Buses operating on Smart Stop routes are fitted with GPS navigation units and an on-board computer.

Ticketing and GPS data are fed into Adelaide Metro's main computer system, which then predicts what time a bus will reach its next stop based on where the bus is and past travel times from that point to the Smart Stop.

Predicted travel time information is relayed to the bus stop and displayed on the Smart Stop display – visually and via audio announcements at the touch of a button.



I can totally see a country 10-15 years from now where every major metropolitan area has its bus lines tracked with GPS. It is efficient, useful, and provides a great service to the public. Also, if cities could spread this type of real time tracking to more than just buses and somehow link up all their transportation services this could really help consumers in their effort to make use of the most efficient transportation available to them. People wouldn’t want to travel by car when they could use the laser like precision of public transportation.

The only way we are going to get away from the energy inefficient modes of transportation is by providing superior alternatives – and it seems like GPS tracking is one of the key components that can make public transportation superior to driving by car.


%%% Figures:
\begin{center}
  % first argument: eps-file
  % second argument: stretching-factor relative to Column-width (<1)
  % optional argument: rotation angle (0-360), default=0
  \myfig[60]{concurrency.pdf}{0.55}
  \mycaption{A diagram (rotated by $60^\circ$).}
\end{center}

\item Directions: a function to find the quickest route by public transport from the user's location to any other location.  Would be similar to the Google Maps function that does the same, if not actually using the Google service.\footnote[1]{This was written almost to completion, but was not included because it was finally noticed that there was no way to use Google Directions data for Public Transit.  Only Walking and Driving were possible.}
\item Arrow indicators for buses: Arrow that indicate the direction of travel of buses.  Perhaps a toggle to enable/disable this to avoid cluttering the screen.  Would be useful for long update intervals and zoomed out views.
\item Time to reach user: a function to display the estimated time a chosen bus will reach the closest point on it's route to the user (or another specified location).
\item Speed: function to display current average speed of chosen bus (or all buses).
\item Stopped indicator: display a different icon for buses that have stopped.
\item History Trail: option to begin drawing trails behind buses, to show history from time activated.
\item Stops: display stops on routes displayed.  Would be very useful for any user in an unfamiliar area.
\item Sift buses/routes by location: function to show only routes that come within a certain radius of a selected point (or perhaps buses that are currently within a certain radius).  The radius could be static or adjustable by dragging.

